【セッションレポート】『構築者に知っておいてもらいたい 運用設計者が語るAWS』 #cmdevio2015H
はじめに
こんにちは植木和樹＠AWS運用担当です。先日弊社で開催したDevelopers.IO 2015にて「構築者に知っておいてもらいたい 運用設計者が語るAWS」という題名でお話しました。本日は内容の紹介と解説となります。
構築者に知っておいてもらいたい 運用設計者が語るAWS
参加者の傾向
当日は15名ほどの方に参加いただきました。Hトラックは監視・運用部屋なので運用メインの方が多いかなと思いましたが、開発構築と保守運用が半々といったところでした。ほとんどの方がAWS利用経験者で、AutoScalingを利用している方は5名ほどという感じでした。
内容と解説
「運用でカバー」でいいんです！ ※
Software Designに書かれている「運用でカバーはダメ」っていうのを否定しているわけじゃありませんってとこご注意ください。アプローチの違いで「運用でカバー」が発生してしまう【原因】をなくしましょうというのがSoftware Desginで語られていて、私は発生してしまうだろう「運用でカバー」をPDCAまわしてちゃんと見直していきましょうというのが伝えたいことです。多くの場合「運用でカバー」は発生してしまうものです。事前の入念な設計も大事ですが、「運用でカバー」が発生した後の見直し体制も考慮しておきましょう。
またPDCAまわすには設計を見直せる権限と技術をもったエンジニア（保守担当者）が不可欠です。一般的に保守担当者は「変更することでおかしくさせるのも嫌だからなるべく触らない」と保守的な考えになりがちです。保守担当者がおそれることなく変更に取り組めるようシステムをわかりやすく保ち、少しずつ変化させましょうというのが続く内容になります。
環境は少しずつ変化させる
1年以上変更のないところに変更を加えるのは相当なコストが必要です。変更箇所の把握、変更実施、テストといった作業だけでなく、関係各所への連絡や変更承認手続きといった点でも時間がかかるのが常です。そのためなるべく小さい単位でシステムを変更・変化させていく体制や仕組みを作っておくのが良いと思います。
わかりやすさが重要
人は忘れます。またシステムの寿命に比べて、担当者の任期は短いのが常です。参加者15名の中でも同じシステムを3年以上担当されている方は、ほんの数名でした。あなたが作ったシステムはきっと別の誰かが保守することになるでしょう。
そのためにもシステムは分かりやすく保ちましょう。自分の作ったシステムが他人からみてわかりやすくなっているか？システムを把握するためのドキュメントが十分に記載されているか？を簡単にチェックする方法としてレビューを勧めています。
技術的に可能だからといってトリッキーな仕組みは作らないでください。（本当にお願いします）
AutoScalingは正義
オンプレのシステムを構成そのままにAWSに移行して満足していないでしょうか？せっかくAWS上でシステムを構築したのですから可用性が高く、コストを低く、保守運用しやすい構成を目指しましょう。
AWSにシステムを構築する際はAutoScalingを1つの目標にしましょう、というのがここで伝えたいことです。可用性やコストの面だけではなく、構成管理や開発プロセスといった体制面でもきっと改善されると思います。
終わりに
セッション終了後に何名かの方から「そうは言ってもいろんな事情があるんだよ」というお話を聞かせていただきました。システムごとにいろんな事情があると思います。しかし「本当にこの苦労はする必要があるのか？」と考え、少しずつでも「運用でカバー」を見直していきましょう。そのために他人はどうしているのかを知ることが大切だと思います。
JAWS-UGの千葉や関西では運用をテーマとして勉強会を開催しています。ぜひお近くのJAWS-UGに参加していろんな方のお話を聞いてみてはいかがでしょうか？
